Views for Reporting, Data Security, and Reusable Queries in MySQL

Course: MySQL Training Course

Topic: Views for Reporting, Data Security, and Reusable Queries

Course Link: MySQL Training Course at JustAcademy

Demo Link: Register for a Free Course Demo

1. Introduction to Views in MySQL

A view in MySQL is a virtual table created from a SELECT query. It presents data from one or more underlying tables without normally storing a separate copy of the result. When a user queries a view, MySQL processes the view definition and returns the matching data.

Views help database developers simplify complicated SQL statements, prepare consistent reports, limit exposure of sensitive columns, and reuse frequently needed queries. They are particularly useful when different users need different representations of the same business data.

1.1 What Is a View?

A view stores a query definition that can be accessed like a table in many SELECT statements. It may retrieve selected columns, filter rows, combine tables using joins, or calculate summary values.

CREATE VIEW employee_public_view AS
SELECT employee_id, employee_name, department
FROM employees;

After creating the view, users can retrieve its data using a familiar SELECT statement.

SELECT *
FROM employee_public_view;

1.2 Example of a Base Table and a View

Consider an employees table containing employee IDs, names, departments, salaries, phone numbers, and email addresses. A reporting team may only need employee names and departments. A view can expose those selected columns instead of requiring the team to query the full table.

1.3 Objectives of Using Views

• Simplify complex SQL queries.
• Create consistent business reports.
• Expose only the columns and rows required by a user.
• Reuse common filtering, joining, and calculation logic.
• Separate the way users access data from the structure of underlying tables.
• Improve maintainability of database queries.

2. Understanding Views for Reporting

Reporting often requires data from multiple tables, calculations, filtering, and grouping. Writing the same query repeatedly can make reports difficult to maintain. A view can store commonly used reporting logic so that reports can retrieve the prepared result using a simpler query.

2.1 Why Views Are Useful for Reporting

• Simplification: Users can query a view instead of rewriting a long SQL statement.
• Consistency: Multiple reports can use the same definitions for calculations and filters.
• Readability: Descriptive view names make queries easier to understand.
• Maintainability: A shared view definition can be updated when reporting requirements change.
• Data presentation: Views can show meaningful column names and calculated fields.

2.2 Creating a Basic Reporting View

Suppose a company has a sales table with the columns sale_id, product_name, region, quantity, unit_price, and sale_date. A report may need the total value of each sale.

CREATE VIEW sales_reporting_view AS
SELECT
    sale_id,
    product_name,
    region,
    quantity,
    unit_price,
    quantity * unit_price AS total_amount,
    sale_date
FROM sales;

The expression quantity * unit_price calculates the total amount for each sale. The result is exposed through the total_amount column.

To retrieve data from the view:

SELECT *
FROM sales_reporting_view;

To display only sales from a particular region:

SELECT product_name, total_amount, sale_date
FROM sales_reporting_view
WHERE region = 'West';

2.3 Creating a Summary Report View

Managers frequently need summarized information rather than individual transactions. Aggregate functions such as SUM(), COUNT(), AVG(), MIN(), and MAX() can be used in reporting views.

CREATE VIEW regional_sales_summary AS
SELECT
    region,
    SUM(quantity * unit_price) AS total_sales,
    COUNT(*) AS number_of_sales,
    AVG(quantity * unit_price) AS average_sale
FROM sales
GROUP BY region;

Retrieve the regional summary:

SELECT *
FROM regional_sales_summary
ORDER BY total_sales DESC;

2.4 Reporting with Joins

Reports often need descriptive information from related tables. For example, an orders table may contain customer_id while a customers table stores customer names and cities. A view can combine them using a JOIN.

CREATE VIEW customer_orders_report AS
SELECT
    o.order_id,
    c.customer_name,
    c.city,
    o.order_date,
    o.order_amount
FROM orders AS o
INNER JOIN customers AS c
    ON o.customer_id = c.customer_id;

Query the report:

SELECT customer_name, order_date, order_amount
FROM customer_orders_report
WHERE city = 'Mumbai'
ORDER BY order_date DESC;

This view allows users to retrieve customer and order information without repeatedly writing the join.

2.5 Filtering Data in a Reporting View

A view can contain a WHERE clause to define which records it presents. For example, a business may create a view containing completed orders only.

CREATE VIEW completed_orders_view AS
SELECT order_id, customer_id, order_date, order_amount
FROM orders
WHERE order_status = 'Completed';

Users can query the view without repeating the completed-order condition.

SELECT *
FROM completed_orders_view
WHERE order_amount > 5000;

Important: A filter inside a view defines the view's result, but users who have access to the underlying tables may still query those tables directly. Use appropriate database privileges when the filter is intended to enforce data access restrictions.

3. Views for Data Security

Data security is a key reason to use views. Business databases may contain confidential information such as employee salaries, customer contact details, payment information, and internal financial records. Different users often need access to different portions of that data.

A carefully designed view can expose only selected columns or rows. Database privileges can then grant users access to the view without granting them unrestricted access to the underlying table.

3.1 How Views Support Data Security

• Column restriction: Exclude sensitive columns from the view.
• Row restriction: Define a view that returns only records relevant to a specific purpose.
• Role-based access: Give reporting users permission to query approved views.
• Data abstraction: Present a simplified structure without exposing every underlying field.
• Reduced accidental exposure: Encourage users to access only the data required for their tasks.

3.2 Hiding Sensitive Columns

Suppose the customers table contains customer_id, customer_name, email, phone, city, and payment_reference. A customer support report may require the customer name and city but not the email, phone, or payment reference.

CREATE VIEW customer_public_view AS
SELECT
    customer_id,
    customer_name,
    city
FROM customers;

Authorized users can retrieve the selected information:

SELECT *
FROM customer_public_view;

The view does not include email, phone, or payment_reference. This reduces exposure through this particular access path, provided users do not also have privileges to read the excluded data from the base table or another object.

3.3 Restricting Rows with a View

Views can also filter records. Consider an orders table where regional teams should work with orders from their assigned region.

CREATE VIEW west_region_orders AS
SELECT
    order_id,
    customer_id,
    order_date,
    order_amount,
    region
FROM orders
WHERE region = 'West';

Query the regional view:

SELECT *
FROM west_region_orders;

This query returns rows matching the view's filter. However, a fixed regional view is not automatically a complete user-specific access-control system. If different users require different regions, use an appropriate authorization design and grant only the required privileges.

3.4 Granting Access to a View

MySQL provides the GRANT statement to assign privileges. The following is an illustrative example that grants read access to a reporting view. Replace the account and database names with the actual values used in your environment.

GRANT SELECT
ON company_db.customer_public_view
TO 'report_user'@'localhost';

To verify the privileges assigned to an account, an administrator can use:

SHOW GRANTS FOR 'report_user'@'localhost';

The account should not have unnecessary privileges on the underlying tables. If it has direct SELECT access to the customers table, the view alone will not prevent it from reading the table's sensitive columns.

3.5 Understanding SQL SECURITY DEFINER and INVOKER

MySQL views support SQL SECURITY DEFINER and SQL SECURITY INVOKER. These options determine whose privileges MySQL uses when checking access to objects referenced by a view.

Example using the definer's security context:

CREATE DEFINER = CURRENT_USER
SQL SECURITY DEFINER
VIEW employee_directory AS
SELECT employee_id, employee_name, department
FROM employees;

Example using the invoking user's security context:

CREATE SQL SECURITY INVOKER
VIEW employee_directory_invoker AS
SELECT employee_id, employee_name, department
FROM employees;

Choose the security mode according to the application's access requirements. A view's security mode does not replace careful privilege management, secure account configuration, or review of the view's definition.

3.6 Security Best Practices

• Grant users only the privileges they need.
• Do not expose confidential columns unless there is a clear business requirement.
• Review row filters to ensure they match the intended access policy.
• Understand the difference between DEFINER and INVOKER security.
• Check whether users have direct access to underlying tables.
• Use separate database accounts for different applications and user groups.
• Review view definitions and privileges when business roles change.
• Avoid placing passwords, secret tokens, or other credentials in view definitions.

4. Views for Reusable Queries

Reusable queries are SQL statements or query definitions that can be used repeatedly without rewriting the same logic. Views are useful when multiple reports, dashboards, or applications need the same columns, joins, filters, or calculations.

4.1 Why Reusable Queries Matter

• Reduce duplicated SQL code.
• Make complex queries easier to read.
• Standardize calculations across reports.
• Reduce inconsistencies caused by independently written queries.
• Make shared query logic easier to maintain.
• Help teams work with common definitions of business metrics.

4.2 Creating a Reusable Query View

Suppose a company repeatedly calculates the total amount of each order by multiplying quantity by unit price. Instead of repeating the expression in every report, create a reusable view.

CREATE VIEW order_details_view AS
SELECT
    order_id,
    product_id,
    quantity,
    unit_price,
    quantity * unit_price AS line_total
FROM order_items;

The view can then be used by different queries:

SELECT *
FROM order_details_view;

SELECT order_id, SUM(line_total) AS order_total
FROM order_details_view
GROUP BY order_id;

The second query reuses the calculated line_total column to produce an order-level summary.

4.3 Reusing a Complex JOIN

Consider a query that combines orders, customers, and employees. If several reports need the same relationship, store it in a view.

CREATE VIEW order_customer_employee_view AS
SELECT
    o.order_id,
    o.order_date,
    o.order_amount,
    c.customer_name,
    e.employee_name AS sales_representative
FROM orders AS o
INNER JOIN customers AS c
    ON o.customer_id = c.customer_id
LEFT JOIN employees AS e
    ON o.sales_rep_id = e.employee_id;

Reports can use this view with different filters and sorting rules.

SELECT *
FROM order_customer_employee_view
WHERE order_amount > 10000;

SELECT sales_representative, COUNT(*) AS order_count
FROM order_customer_employee_view
GROUP BY sales_representative;

4.4 Reusing Business Calculations

A business may define a high-value order as an order with an amount greater than 10000. The definition can be represented in a view.

CREATE VIEW high_value_orders AS
SELECT
    order_id,
    customer_id,
    order_amount,
    order_date
FROM orders
WHERE order_amount > 10000;

Multiple users can query the same definition:

SELECT COUNT(*) AS high_value_order_count
FROM high_value_orders;

SELECT customer_id, SUM(order_amount) AS total_value
FROM high_value_orders
GROUP BY customer_id;

Centralizing a business rule in a view can reduce differences between reports. When the rule changes, the view definition can be updated and dependent reports reviewed.

4.5 Views and Common Table Expressions

Views and common table expressions (CTEs) can both make SQL easier to read, but they serve different purposes.

Example of a CTE:

WITH regional_totals AS (
    SELECT region, SUM(order_amount) AS total_sales
    FROM orders
    GROUP BY region
)
SELECT region, total_sales
FROM regional_totals
WHERE total_sales > 50000;

Use a view when the query definition needs to be shared across multiple statements or users. Use a CTE when the named logic is primarily needed for one statement.

5. Creating and Managing Views

5.1 CREATE VIEW Syntax

CREATE VIEW view_name AS
SELECT column1, column2
FROM table_name
WHERE condition;

The view name should be descriptive and should follow the database's naming conventions.

5.2 CREATE OR REPLACE VIEW

MySQL supports CREATE OR REPLACE VIEW to create a view if it does not exist or replace its definition if it already exists. This is useful when reporting requirements or security rules change.

CREATE OR REPLACE VIEW active_customers_view AS
SELECT customer_id, customer_name, city
FROM customers
WHERE status = 'Active';

Replacing a view changes its query definition; it does not automatically grant the desired privileges to every user. Review dependent queries and access permissions after making changes.

5.3 ALTER VIEW

ALTER VIEW modifies the definition of an existing view without using CREATE OR REPLACE. It is useful when the selected columns or query logic need to change.

ALTER VIEW active_customers_view AS
SELECT customer_id, customer_name, city, status
FROM customers
WHERE status = 'Active';

5.4 Displaying a View Definition

Use SHOW CREATE VIEW to inspect the SQL definition of a view.

SHOW CREATE VIEW active_customers_view;

This helps developers verify selected columns, filters, joins, and view security characteristics.

5.5 Listing Views

Use SHOW FULL TABLES to list tables and views in the selected database.

SHOW FULL TABLES
WHERE Table_type = 'VIEW';

5.6 Dropping a View

When a view is no longer needed, it can be removed using DROP VIEW. Dropping a view removes the view object, not the underlying base tables or their records.

DROP VIEW IF EXISTS active_customers_view;

Before dropping a view, check whether dashboards, reports, applications, or other views depend on it.

6. Combining Reporting, Security, and Reusable Queries

A well-designed view can support more than one purpose. For example, a sales reporting view may calculate order totals, join customer information, and exclude confidential payment fields. Authorized users can reuse it in dashboards and reports.

6.1 Example Business Scenario

Assume a company has these tables:

• customers: customer_id, customer_name, city, email.
• orders: order_id, customer_id, order_date, order_amount, order_status.

The management team needs a report containing customer names, cities, order dates, amounts, and statuses. It does not need customer email addresses.

CREATE VIEW management_orders_report AS
SELECT
    o.order_id,
    c.customer_name,
    c.city,
    o.order_date,
    o.order_amount,
    o.order_status
FROM orders AS o
INNER JOIN customers AS c
    ON o.customer_id = c.customer_id;

Retrieve the report:

SELECT *
FROM management_orders_report
ORDER BY order_date DESC;

Summarize completed orders by city:

SELECT
    city,
    COUNT(*) AS completed_order_count,
    SUM(order_amount) AS completed_sales
FROM management_orders_report
WHERE order_status = 'Completed'
GROUP BY city
ORDER BY completed_sales DESC;

6.2 Benefits of This Design

• The customer and order join is defined once.
• The view exposes only the columns required for the report.
• Multiple reports can reuse the same source definition.
• Additional filters and aggregations can be applied when querying the view.
• Access can be granted to the view separately from the underlying tables.

Remember that excluding email from the view does not protect it if a user can also query the customers table directly. Security depends on the complete privilege configuration, not only on the view definition.

7. Performance Considerations When Using Views

Views simplify query development, but they do not automatically make queries faster. MySQL processes a view using its query definition and the underlying tables. Actual performance depends on the query, joins, filters, indexes, data volume, and the execution plan.

7.1 Performance Best Practices

• Select only the columns needed by the report.
• Use appropriate indexes on underlying tables for joins and frequently filtered columns.
• Avoid unnecessarily complicated nested views.
• Inspect query plans using EXPLAIN.
• Test views with realistic data volumes.
• Avoid assuming a view stores a permanent copy of its results.
• Review whether aggregation or filtering can be simplified.

7.2 Using EXPLAIN

EXPLAIN helps you inspect how MySQL plans to execute a query that references a view.

EXPLAIN
SELECT *
FROM management_orders_report
WHERE city = 'Mumbai';

Review the tables accessed, possible indexes, selected access methods, and estimated rows. Use the execution plan to identify areas that may need optimization.

7.3 Views Are Not Automatically Materialized

A standard MySQL view is a stored query definition rather than a separate stored copy of the result set. Querying the view generally involves processing its underlying query. MySQL's view processing algorithm and the specific query can affect execution behavior.

For performance-sensitive workloads, measure query execution and evaluate indexes, query structure, and suitable caching or summary-table strategies where appropriate.

8. Limitations of MySQL Views

• Views do not automatically improve query performance.
• Some complex views are not updatable.
• Changes to underlying table structures can cause dependent views to fail.
• Nested views can make query behavior harder to troubleshoot.
• Views do not replace a complete security and privilege-management strategy.
• Creating or replacing a view may require specific privileges.
• A view definition does not automatically include new columns added later to a base table when the view was defined using SELECT *.
• Aggregate functions, grouping, joins, and other query features may affect whether a view can be updated.

9. Common Errors and Troubleshooting

9.1 Troubleshooting Checklist

1. Confirm that the view exists in the intended database.
2. Inspect the view definition using SHOW CREATE VIEW.
3. Verify that all referenced tables and columns exist.
4. Run and test the underlying SELECT query separately where practical.
5. Review joins, filters, aggregate expressions, and aliases.
6. Check the user's privileges on the view and its dependencies.
7. Use EXPLAIN if performance is a concern.
8. Test reports after changing a view definition.

10. Best Practices for Designing Views

• Use meaningful names such as monthly_sales_report or customer_public_view.
• Keep view definitions focused on a clear business purpose.
• Avoid SELECT * in views intended for long-term reporting or security boundaries.
• Use explicit column names and readable aliases.
• Centralize shared business calculations when doing so improves consistency.
• Grant the minimum required privileges to each database account.
• Document important filters and calculations.
• Check downstream reports before changing or dropping a view.
• Test security settings with the actual user accounts that will query the view.
• Measure performance rather than assuming a view makes a query faster.

11. Practical Project: Build a Secure Sales Reporting System

11.1 Project Objective

Create reusable MySQL views for sales reporting and customer data access. Use the views to simplify reporting queries while limiting the fields exposed to reporting users.

11.2 Sample Table Structure

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    city VARCHAR(60),
    email VARCHAR(150)
);

CREATE TABLE sales_orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    order_date DATE,
    quantity INT,
    unit_price DECIMAL(10,2),
    order_status VARCHAR(30),
    FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
);

11.3 Insert Sample Data

INSERT INTO customers
(customer_id, customer_name, city, email)
VALUES
(1, 'Aarav Sharma', 'Mumbai', '[email protected]'),
(2, 'Meera Patel', 'Pune', '[email protected]'),
(3, 'Rohan Verma', 'Mumbai', '[email protected]');

INSERT INTO sales_orders
(order_id, customer_id, order_date, quantity, unit_price, order_status)
VALUES
(101, 1, '2026-01-10', 3, 500.00, 'Completed'),
(102, 2, '2026-01-12', 2, 1200.00, 'Pending'),
(103, 3, '2026-01-15', 5, 250.00, 'Completed');

11.4 Create a Reusable Sales View

CREATE VIEW sales_order_report AS
SELECT
    s.order_id,
    c.customer_name,
    c.city,
    s.order_date,
    s.quantity,
    s.unit_price,
    s.quantity * s.unit_price AS total_amount,
    s.order_status
FROM sales_orders AS s
INNER JOIN customers AS c
    ON s.customer_id = c.customer_id;

11.5 Create a Customer View Without Email

CREATE VIEW customer_basic_info AS
SELECT customer_id, customer_name, city
FROM customers;

11.6 Run Reporting Queries

Display all sales records:

SELECT *
FROM sales_order_report;

Display completed orders:

SELECT order_id, customer_name, total_amount
FROM sales_order_report
WHERE order_status = 'Completed';

Calculate sales totals by city:

SELECT city, SUM(total_amount) AS city_sales
FROM sales_order_report
WHERE order_status = 'Completed'
GROUP BY city;

Display customer information without email addresses:

SELECT *
FROM customer_basic_info;

11.7 Project Security Task

Create a dedicated reporting account and grant it access to the views it needs. Test that the account can query the approved views and cannot access restricted base-table columns directly. Perform account creation and privilege changes only with appropriate administrative authorization.

11.8 Expected Learning Outcomes

• Build a view using multiple tables and a calculated column.
• Reuse a view in several reporting queries.
• Summarize data using aggregate functions.
• Expose selected columns through a view.
• Understand why view definitions and database privileges must work together.

12. Practice Exercises

1. Create an employee view containing employee ID, name, and department, but not salary.
2. Create a view that displays only completed orders.
3. Create a sales summary view that groups total sales by region.
4. Create a view that joins customers and orders.
5. Use a view to calculate total order amounts from quantity and unit price.
6. Replace an existing view using CREATE OR REPLACE VIEW.
7. Inspect a view definition using SHOW CREATE VIEW.
8. Grant SELECT access to a reporting view and inspect the assigned privileges.
9. Use EXPLAIN to examine a query that selects data from a view.
10. Explain why a view that omits a sensitive column does not protect that column if a user still has direct access to the base table.

13. Exercise Solutions

Solution 1: Employee Directory

CREATE VIEW employee_directory AS
SELECT employee_id, employee_name, department
FROM employees;

Solution 2: Completed Orders

CREATE VIEW completed_orders AS
SELECT order_id, customer_id, order_date, order_amount
FROM orders
WHERE order_status = 'Completed';

Solution 3: Regional Sales Summary

CREATE VIEW regional_sales AS
SELECT region, SUM(order_amount) AS total_sales
FROM orders
GROUP BY region;

Solution 4: Customer Order Report

CREATE VIEW customer_order_details AS
SELECT c.customer_name, o.order_id, o.order_date, o.order_amount
FROM customers AS c
INNER JOIN orders AS o
    ON c.customer_id = o.customer_id;

Solution 5: Calculated Order Line Total

CREATE VIEW order_line_totals AS
SELECT order_id, quantity, unit_price,
       quantity * unit_price AS line_total
FROM order_items;

Solution 6: Replace an Existing View

CREATE OR REPLACE VIEW employee_directory AS
SELECT employee_id, employee_name, department, job_title
FROM employees;

Solution 7: Inspect a View

SHOW CREATE VIEW employee_directory;

Solution 8: Grant View Access

GRANT SELECT
ON company_db.employee_directory
TO 'report_user'@'localhost';

SHOW GRANTS FOR 'report_user'@'localhost';

Solution 9: Inspect Query Performance

EXPLAIN
SELECT *
FROM completed_orders
WHERE customer_id = 1;

Solution 10: Security Explanation

A view limits the columns it presents through that view. If a user also has SELECT permission on the original table, the user may query the excluded columns directly. Therefore, the administrator must review and restrict base-table privileges as part of the overall security design.

14. MySQL Interview Questions and Answers

Q1. What is a view in MySQL?

A view is a virtual table defined by a stored SELECT query. It presents data from underlying tables or other views.

Q2. How are views useful in reporting?

Views simplify complex queries, standardize business calculations, and provide reusable data structures for reports and dashboards.

Q3. How can a view help protect sensitive data?

A view can exclude confidential columns or filter rows. To make this effective, users must not have unauthorized direct access to the underlying tables or other objects containing the same data.

Q4. Does a standard MySQL view store a separate copy of its data?

No. A standard view stores the query definition and generally obtains its result from the underlying objects when queried.

Q5. Can a view combine multiple tables?

Yes. A view can use joins to combine related information from multiple tables.

Q6. What is CREATE OR REPLACE VIEW?

It creates a view if one does not exist or replaces the definition of an existing view.

Q7. What is the difference between a view and a base table?

A base table stores records, while a standard view represents the result of a stored query over database objects.

Q8. What is SQL SECURITY DEFINER?

It specifies that underlying object privileges are checked using the view definer's security context.

Q9. What is SQL SECURITY INVOKER?

It specifies that underlying object privileges are checked using the invoking user's security context.

Q10. How do you view a view's definition?

Use SHOW CREATE VIEW view_name;

Q11. Can a view contain aggregate functions?

Yes. A view can use aggregate functions such as SUM(), COUNT(), and AVG() to provide summarized data.

Q12. Do views always improve performance?

No. Views primarily support abstraction and reuse. Performance depends on the underlying query, execution plan, indexes, and data volume.

Q13. What is the difference between a view and a CTE?

A view is a stored database object that can be reused across statements. A CTE is normally scoped to a single SQL statement.

Q14. What happens if an underlying table is dropped?

A view that depends on the dropped table may fail when queried because its dependency is no longer available.

Q15. How can you grant access to a view?

Use GRANT with the appropriate privilege, such as SELECT, on the view, and review whether the user has unnecessary privileges on underlying tables.

15. Quick Revision Checklist

• A view is a virtual table defined by a SELECT query.
• Reporting views simplify complex queries and standardize calculations.
• Views can use joins, filters, expressions, and aggregate functions.
• Views can exclude sensitive columns or restrict which rows they present.
• GRANT and REVOKE help control access to database objects.
• SQL SECURITY DEFINER and INVOKER determine the security context used for underlying privilege checks.
• Reusable views reduce duplicated SQL logic.
• CREATE OR REPLACE VIEW can update an existing view definition.
• SHOW CREATE VIEW displays a view's definition.
• EXPLAIN helps examine query execution plans.
• A view alone does not guarantee data security or better performance.
• Test view behavior, privileges, and dependent reports after changes.

16. Conclusion

MySQL views are valuable tools for reporting, data abstraction, access control, and reusable SQL queries. They help developers organize complex joins and calculations into consistent, readable definitions. Reporting views can make dashboards easier to maintain, while carefully designed security views can expose only the information required by approved users.

For reliable results, combine views with appropriate database privileges, meaningful naming conventions, testing, and query-performance analysis. Always verify that users cannot bypass a view's intended restrictions through direct access to underlying tables.

Learn more: Explore MySQL Training at JustAcademy

Book a demo: Register for a MySQL Course Demo